Amazing, thanks a lot! 🚀

@meyerlor could you add an end2end test ?

added two tests:

1. for the "deactivate all" button
2. for the single layer button

Do you want to backport it to 3.9 or as it's a new feature just backport it to 3.10?

added two tests:

1. for the "deactivate all" button

2. for the single layer button

Do you want to backport it to 3.9 or as it's a new feature just backport it to 3.10?

Thanks for added tests!

I think it's a new feature and it has just to be backported to 3.10.

If I understand correctly, the previous changes made around the filter feature bring (nice) improvements which IMHO could lead to misbehaviours in the present state of the code.

Let me try to explain : when the filter tool was developed (the first time the attribute table tool was added to LWC), we restricted it to be able to filter only one layer at a time.

We did so because the filtered layer could be in relationships with child layers. We developed the cascading filter feature allowing to filter all children layers (and children of children). This was complex at the time (mainly because of the possibility to have pivot table A <- pivot -> B and be sure to not go in an infinite loop of filters). We did not develop it with recent "State based" tools. So this part of the code is fragile I think.

Since the recent changes, it seems to me we can now have more than one active filter ? If so, I think there can be collision between layers depending on theirs relationships. Imagine a child layer beeing filtered from the parent, and also with the form filter tool. How do we consolidate the filter for this layer at present (I think we don't yet)

We planed with @rldhont to refactor the whole code around the attribute table to detach the filtering feature, and build a proper "filter" state allowing to better control which layers were filtered, how the filter should be built and how it is discovered and shared among the different tools (time manager, form filter, attribute table, etc.).

We could create a new issue for discussion purpose. What do you think @rldhont @meyerlor @mind84 ?

@mdouchin,

+1 for creating a dedicated issue. Also, I think it's worth making the filtering functionality stable on multiple levels at the same time. There are cases where this feature would be very convenient, such as the ability to view a set of historical data by filtering on the validity of the records. This isn't a particularly common request, but sometimes such needs arise.

+1
same from me, a dedicated discussion issue seems a good idea!
I had no time yet to test if those remaining PR's make trouble with the child features filter. I will test it thoroughly as soon i find the time!